A multimodule architecture is composed of several distinct physical entities that are connected to one another through a fast link operating at the level of the system bus, generally of the SCI type, from the abbreviation for Scalable Coherent Interface.
Each entity, hereinafter called a module, is equipped with means for connecting the module to the fast link.
The functionality of a module can be expanded to the management of independent machines, particularly in order to perform a “server consolidation.”
The modules generally have a management means called a “Service Processor” (SP), also known as a “BUMP,” from the abbreviation for “BringUp Microprocessor,” that works like an independent central processor, used during the startup and shutdown of the modules, and in order to perform the monitoring of the modules.
The constraints linked to this functionality can be summarized as follows:                it is necessary to ensure the synchronous startup of the modules of a machine, given that the machine does not have “global” physical mechanism for starting all of the modules, each module having its own physical start mechanism (push button or key);        it is necessary to automatically modify the configuration of each machine in case of a failure of a module or of the fast link and reboot the machine, the BUMPs of the various modules not being connected to one another and hence not being able to perform this modification;        finally, the states of the various modules must be visible through a graphical interface that allows the dynamic display of the states of the various modules.        
One possible solution would consist of adding the hardware required to obtain the “global” on/off function.
Such a solution would require the modification of the modules so that they accommodate this new hardware “globally,” without taking their own on/off hardware into account.
Another solution would consist of interconnecting the various BUMPs so they can decide on the configuration modifications themselves. This solution would require the addition of hardware for connecting the BUMPs. Moreover, this solution would require complex developments at the “firmware” level, i.e., at the level of the programming software of the BUMP, in order to be able to manage this connection, analyze failures and decide on the configuration modifications to be performed.
It would also be possible to use a graphical screen connected directly to the machine. However, this solution would not make it possible to manage the machine when the system is not running, i.e., when the machine is stopped and under the control of the BUMPs.